Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@quenty/servicebag

Package Overview
Dependencies
Maintainers
1
Versions
177
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@quenty/servicebag

Service providing mechanisms for Nevermore

  • 7.2.0
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
367
decreased by-10.71%
Maintainers
1
Weekly downloads
 
Created
Source

ServiceBag

Documentation status Discord Build and release status

Service providing mechanisms for Nevermore

Installation

npm install @quenty/servicebag --save

Goals

  • Remove requirement for many services to be loaded
  • Make installing new modules really easy
  • Make testing easier
  • Reduce maintaince costs
  • Explicitly declare service pattern
  • Force declaration of service usage
  • Make it easy to trace service dependencies

Requirements

  • Initialize dependent services using :Init()
  • Start dependent services using :Start()
  • Retrieve services is easy
  • Don't have to list off every service in the game
  • Services don't load until we ask them to
  • Circular dependencies allowed

Like-to-have

  • Dependency injection for tests
  • Works with type system GetService<IService>()
  • Async initialization (return promises instead of blocking)
  • Dependency graph safe (i.e. recursive service requirement )
  • Services are protected from another service erroring

Stretch goals

  • Handles services for actors (remove global code)

Ideas

  • Inject a ServiceBag

Rules

  1. Each service will be identified by its module
  2. Each service will be initialized once
  3. If we require a service, we will not have to declare subservices
-- Main script
local serviceBag = require("ServiceBag").new()

serviceBag:AddService(require("TransparencyService"))

serviceBag:Init()
serviceBag:Start()
-- Other script
local TransparencyService = require("TransparencyService") -- force declaration at top

local TestClass = {}
TestClass.ClassName = "TestClass"
TestClass.__index = TestClass

function TestClass.new(serviceBag)
	local self = setmetatable({}, TestClass)

	self._serviceProvider = assert(serviceBag, "No serviceBag")

	self._transparencyService = self._serviceProvider:GetRequiredService(TransparencyService)
	
	return self
end

return TestClass
local DialogPane = setmetatable({}, BasicPane)
DialogPane.ClassName = "DialogPane"
DialogPane.__index = DialogPane

function DialogPane.new(serviceBag)
  local self = setmetatable(BasicPane.new(serviceBag:GetService(DialogTemplatesClient):Clone("DialogPaneTemplate")), DialogPane)

  self._theme = Instance.new("StringValue")
  self._theme.Value = "Light"
  self._maid:GiveTask(self._theme)

  self._dialogInput = DialogInput.new()
  self._maid:GiveTask(self._dialogInput)

Classes versus singletons

Right now services and classes aren't the same. There's no contract to transform a class with lifetime into a service. However, because some of our services actually implement a .new() method (i.e. service definitions can be classes), we can't differentiate easily.

The issue is around life-cycle.

  1. Service.new() can either be a constructor which establishes just data for the service or...
  2. Service.new() can actually establish state data.

Other service providers solve this issue by doing the following...

  1. Separating out the service identifier from the actual service definition (interfaces)
  2. Separating out the addition of services from the actual services

We inherently don't want to separate out interfaces yet because we don't know what the actors or tie-interfaces for hot reloading will even look like.

It's important that we don't define this yet because there's a good chance separation at the service layer will be very important (i.e. we'll want to observe service state existing).

Potential solution: Interface provision

We could establish a contract that providing an interface will be allowed. That is, a service can return a value it'd like to use as an interface instead. We may need to wait until we resolve these other problems first.

Major changes in the future

  1. Require-by-name
  2. Interfaces as definition
  3. Hot reloading
  4. Async interfaces

Keywords

FAQs

Package last updated on 08 Jan 2024

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc